Hi,

I recently wanted to chain two Modlishka instances together to form an authentic ruse but there was a problem that resulted in a functional patch. I've tested it on an active engagement without issue and thought it would be beneficial to contribute.

The Problem

• The first Modlishka server proxied for a Citrix ShareFile service
• During SSO authentication, the victim's browser was redirected from ShareFile to Microsoft
• I wanted to proxy for this domain as well while maintaining authentic hosts as opposed to encrypted hostnames
• Current logic did not facilitate updates the FQDN of the Location header while rewriting the HTTP response
• This broke the man-in-the-middle position, resulting in the victim's browser being redirected to login.microsoftonline.com

The Solution

• A new configuration parameter, staticLocations, was added that allows configuration of allowed FQDNs in the Location header that will not be converted to the current phish domain via runtime.RealURLtoPhish
  • This allows us to control which upstream locations the Modlishka proxy will forward to
• A patch to the function that rewrites the response body was applied that:
  • Updates the location header with all values in runtime.ReplaceStrings
    • This allows one to update the FQDN in the location header to the desired host
  • Searches through each static location and determines if the Location header should be updated via runtime.RealURLtoPhish
    • If a match on a static location is observed then it will not be updated to match the phish FQDN
• Once authentication is finished, a termination is triggered that results in the victim being redirected back to the ShareFile page to download a malicious payload :)

The Outcome

I refer to each Modlishka server as a stage to make this easier to digest. The sections below describe each server configuration and the final request flow.

Server Configurations

This configuration allowed me to chain two Modlishka servers:

Note: Alias S1M reads like "Stage 1 Modlishka"

S1M Configuration File

{
    ...
    "rules":"bWljcm9zb2Z0b25saW5lLmNvbQ==:b3BoaXNoMzY1LmNvbQ==",
    "staticLocations":"login.ophish365.com",
    ...
}

S2M Configuration File

{
    ...
    "rules":"d3d3LnNoYXJlZmlsZS5jb20=:d3d3LnNoYXJmaWxlLmNvbQ==",
    "staticLocations":"www.sharfile.com",
    ....
}

Final Request Flow

1. Victim clicks phishing link; lands on www.sharfile.com
2. Clicks "Sign In"
3. S1M rules configuration changes login.microsoftonline.com to login.ophish365.com
4. S1M observes that login.ophish365.com is a staticLocation value, redirects to S2M
5. S2M receives redirect; renders login.ophish365.com
6. Victim submits valid credentials
7. Victim's browser lands on the /kmsi resource, provoking termination and redirect back to www.sharfile.com
8. Profit by injecting static HTML page with link to MalDoc